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TECHNICAL FIELD 

The present invention relates to electronic commerce 
systems, and more particularly, to a system enabling 
interaction between legacy components of an electronic 
10 commerce system. 
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BACKGROUND OF THE INVENTION 

The expansion of the Internet has provided businesses and 
individuals with increased opportunity to perform business 
transactions (i.e., e-commerce) on a large scale. Today's e- 
5 commerce solutions are almost exclusively performed as unique, 
single implementation systems. A system must be implemented 
from scratch with no connection or interaction with other 
types of systems. This can create high implementation costs 
for individuals attempting to begin their own e-commerce 

10 business or for existing businesses expanding their business 
into the e-commerce realm. 

Existing e-commerce transactions are normally classified 
as one of two types, business to business (B2B) and business 
to consumer (B2C) . The reasons for this are the perceived 

15 differences between the functionality of the two tracks. 
However, there really are no great differences between the two 
types of e-commerce transactions. Both require strong 
authentication, connection to an underlying business system 
and a proven transaction engine. Existing systems are unable 

20 to interconnect the separate entities required for an 
electronic commerce transaction and integrate them into a 
single viable system. This requires each new e-commerce 
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solution to comprise a unique entity built from scratch. This 
causes the cost of launching and maintaining a system to be 
high in terms of initial investment and support. 

A merchant wishing to implement a web shop today has two 
5 choices. The merchant may host a complete web shop himself, 
complete with the required business system, access control 
systems, security systems, transaction systems, etc., or the 
merchant may outsource the entire operation to an independent 
service provider. Neither of these solutions are optimal. 

10 When the merchant implements the system, the merchant is 
required to bear the cost of implementing and maintaining the 
hardware, software and human resources associated with the 
electronic commerce system. The second scenario, while less 
costly, is also less flexible for the merchant because all 

15 changes in the web shop must be performed by the service 
provider. The second scenario also limits the amount of 
current information a merchant is able to obtain with respect 
to sales on the web shop. 

In both of these cases, each consumer and merchant is 

20 required to enter into a separate business relationship 
instead of negotiating a single relationship with a trusted 
third party. This means that a consumer doing business with 
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ten separate merchants must have ten separate deals, one with 
each merchant. Therefore, a need has arisen for a system 
enabling the integration of a plurality of different systems 
necessary for performing an electronic commerce transaction in 
5 such a manner that does not require a complete construction, of 
an electronic commerce system for a new merchant wishing to 
open a web shop. 



SUMMARY OF THE INVENTION 

The present invention overcomes the foregoing and other 
10 problems with a system enabling the performance of electronic 
commerce transactions which includes a central controller for 
integrating together at least one of business systems, 
transaction systems, identification systems or presentation 
systems with the central controller enabling the exchange of 
15 data relating to an electronic commerce transaction 
therebetween. The central controller provides logic to 
support an e-commerce transaction using the various systems. 
The solution enables the use of several access and security 
methods, not just one single method. The solution provides 
20 for "multi channel" payments, meaning that a central 
controller offers to the Merchants one and the same payment 
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solution using different transaction media. Likewise, the 
Consumers can pay using one and the same payment solution 
using different transaction media. The solution is 

transparent to which means of communications is used by 
5 vendors and customers. Application program interfaces (API) 
associated with the central controller enable communications 
between the central controller and the business systems, 
transaction systems, identification systems and presentation 
systems. The APIs include at least a first layer supporting 
10 a first communication protocol used by the central . controller 
and a second layer for supporting a second communications 
protocol used by one of the other systems . 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method and apparatus 
15 of the present invention may be obtained by reference to the 
following Detailed Description when taken in conjunction with 
the accompanying Drawings wherein: 

FIGURE 1 is a functional block diagram of the electronic 
commerce system of the present invention; 
20 FIGURES 2a and 2b illustrate communications through an 

API; 
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FIGURES 3 provides a more detailed illustration of the 
API between the middleware and a legacy system; 

FIGURES 4 provides an illustration of the various objects 
stored within the database of the middleware; 
5 FIGURE 5 illustrates various logical applications 

included within the middleware; 

FIGURE 6 illustrates an example of a browser transaction 
using the system of the present invention; 

FIGURE 7 illustrates a mobile SMS transaction using the 
10 system of the present invention; and 

FIGURE 8 illustrates a business to business transaction 
using the system of the present invention. 



DETAILED DESCRIPTION 

Referring now to the drawings, and more particularly to 
15 FIGURE 1, there is illustrated an electronic commerce system 
10 operating according to the present invention. The 
electronic commerce system 10 consists of a plurality of 
legacy systems 15 such as a business system 15a, transaction 
system 15b, identification systems 15c and presentation 
20 systems 15d. The legacy systems 15 interact through a core 
system 35 referred to as the middleware. 
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The middleware 35 implements a number of APIs 40 enabling 
communications between the various legacy systems 15 and the 
middleware 35. The middleware 35 also implements the core 
logic of the electronic commerce system 10 controlling how 
5 transactions are handled and how information is moved around 
within the electronic commerce system 10. The middleware 35 
comprises an application server with EJB management, covering 
logic, implementation objects and database activity. The 
middleware 35 includes an application server 45 which manages 

10 the electronic commerce system's 10 internal logic and handles 
the provision of services amongst the various legacy systems 
15. The middleware 35 is able to act as a service binder 
between each of the legacy systems 15. A call from one legacy 
system 15 may result in data retrieval from another legacy 

15 system 15 or may simply be handled by the core logic of the 
middleware. A database 55 stores system fundamental data, 
certificate relationships, names, identification of system 
members and system objects. All control of transactions are 
configured with the database 55 within the middleware 35 which 

20 is in turn used by the various core logic applications 45. A 
CORBA naming service 50 assists in controlling the APIs 40 in 
a HOP fashion. The CORBA naming service 5 0 makes external 
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legacy systems visible to the middleware 35, using the APIs 
40. The legacy systems 15 include the various systems 
necessary to perform an e-commerce transaction. 

The business systems 15a comprise legacy systems 
5 containing invoicing, consumer and merchant data and 
functionalities. As a practical matter, literally thousands 
of business systems exist. Most of these are tightly 
integrated with a company's daily operations and do not 
support standard protocols for communication with external 

10 systems. The transaction systems 15b comprise a set of 
servers and legacy systems for managing financial 
transactions. This may consist of a server provided by a bank 
for a balance/withdrawal/deposit manager. The transaction 
systems 15b manage financial transactions and keep records of 

15 the transactions. The transaction systems 15b handle tasks 
such as supporting standard APIs for micropayments, managing 
transactions between an Internet payment provider and a 
merchant, keeping track of payments and refunds, keeping track 
of customer's account balances and keeping track of merchant's 

20 account balances. 

The identification systems 15c comprise software and 
hardware enabling services to determine whether a consumer or 
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merchant is valid within a particular system. Identification 
systems 15c also manage the verification of purchases. 
Various examples of identification services include dial -in 
caller ID and external identification systems such as 
5 customer databases, certificate generators, CID (caller ID) 
certificate verifiers and CID servers. Verification of 
purchases may be done using X509 certificates and replies to 
SMS messages. The presentation subsystems 15d comprise 

a set of hardware and software servers for offering a 

10 graphical user interface to the electronic commerce system 
10. For a merchant, the merchant's own web server comprises 
part of a presentation system 15d. For a customer, their 
Internet browser would comprise part of the presentation 
systems 15d. The presentation system servers offer common web 

15 based UI (user interface) for merchants and consumers as well 
as for the administrative personnel like consumer support and 
administration . 

The API 40 enable communications between the middleware 
35 and the various legacy systems 15. Each API 40 contains 

2 0 two adaptor layers, enabling the support of two different 
interface standards. CORBA and EJB adapters 60 enable 
communication with EJB interfaces and CORBA IDL interfaces. 
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Additionally, adapters using remote method invocation (RMI) 
and MQ (for mainframes) may also be used. The legacy system 
adapters 65 comprise small customized modules for each 
external legacy system 15 unable to communicate using the more 
5 common • EJB and CORBA IDL interfaces. The legacy system 
adapters 65 speak the legacy system protocol, for example, XML 
message driven protocols, etc. The legacy system adaptors 65 
are represented as API interfaces in either CORBA, IDL or EJB 
formats . 

10 Referring now to FIGURES 2A and 2B, there is illustrated 

how the API 40 enables interaction between the middleware 35 
and a legacy system 15 using either the CORBA and EJB 
interface 60 or the legacy system interface 65. As shown in 
FIGURE 2A, when the legacy system supports CORBA or EJB 

15 interfaces, the middleware 35 and legacy system 15 communicate 
directly. However, if the legacy system 15 does not support 
CORBA or EJB interfaces, the legacy systems adaptor 80 must be 
utilized to enable communication between the middleware 
application 35 and the legacy system 15. 

20 Referring now to FIGURE 3, there is provided a generic 

illustration of an interconnection between the middleware 35 
and a legacy system 15. The API 40 comprises two halves that 
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represent middleware and legacy identification systems, 
respectively. The middleware portion 60 is part of the 
middleware application 35. The legacy system portion 65 is a 
customized portion. The two portions enable each system to 
5 utilize each other's functionality. When integrating a legacy 
system 15, the legacy system portion 65 is unique. The legacy 
system portion 65 is customized for the particular legacy 
system 15 with which the middleware 35 is connected. The 
middleware portion 60 of the adaptor 80 virtually never 

10 changes when integrating with a new legacy system 15. The 
middleware 35 is completely invisible to the legacy system 15 
and the same is true for the legacy system 15 with respect to 
the middleware 35, The middleware 35 and legacy system 15 
only "see" the adaptor 80. If the legacy system 15 supports 

15 either EJB or CORBA interfaces, then the legacy system 
portion 65 of the API 4 0 may become obsolete. However, some 
type of initialization logic may be implemented within the 
legacy system portion 90. Each API 40, whether 

interconnecting the middleware application 35 to a business 

20 system 15a, transaction system 15b, identification system 15c 
or presentation system 15d, is configured in the exact same 
manner. With the middleware portion 60 of the API 40 being 
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virtually unchanged for any application and the legacy system 
portion 65 uniquely configured to whichever legacy system 15 
is being interfaced. 

Referring now to FIGURES 4 and 5, there are illustrated 
5 the various objects and applications which may be implemented 
within the middleware 3 5 in order to provide the middleware 3 5 
with the ability to integrate the various legacy systems 15 
into a cohesive electronic commerce system 10. The various 
objects are stored within the database 55 of the middleware 

10 35. The applications are implemented within the server 45. 

With respect to the identification legacy systems 15c the 
middleware 35 contains identification objects 120 which are 
mainly identification data used as parameters for any 
authentication or registration mechanisms. Examples of these 

15 types of objects include consumer Social Security numbers 
120A; caller ID numbers 120B; merchant organization numbers 
120C; business partner receipts 120D, etc. The various 
applications associated with the identification applications 
130 implemented within the middleware 35 include applications 

20 that make it possible to manipulate, create, and search data 
within interconnected legacy systems 15. These include 
digital certificates generators 130A, encryption/decryption 
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workers 130B, single registration without authentication 
process 130C, single registration using a legacy 
identification process 130D, batch registrations 130E, and 
business object specific applications 130F. 
5 Features provided by the middleware 35 relating to the 

business legacy systems include business objects 140 relating 
to consumers, merchants and transactions. Business 
applications 150 make it possible to manipulate, create and 
search data between two interconnected systems. The business 

10 applications 150 enable updates, the creation of data, the 
deletion of data searching for particular data or other 
business object specific functions. 

The transaction objects 180 and applications 190 include 
objects comprising data fetched from various databases and 

15 bundled together logically in groups such as consumers, 
merchants, transactions, accounts and miscellaneous. 
Applications 190 associated with the transaction system 
include logic making it possible to manipulate, create and 
search data between two interconnected systems. Applications 

20 190 may relate to updates, creation of data, deletion of data, 
searching for data and other business objects. 
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Features relating to the presentation legacy systems 
include objects 160 and applications 170 related to the 
presentation systems. Presentation objects are user-based 
sessions. Session objects 160 are role-based sessions wherein 
5 access to various functionalities is restricted by the role 
played by the system user. Access can be limited to consumer 
sessions, merchant sessions, support sessions, or 
administration sessions. The session applications 170 create 
tags created specifically to be used in a web environment. 
10 The applications 170 available to a user are highly flexible 
and can be easily redefined via updates, creation and deletion 
of data, searching, displaying and business object specific 
functions . 

Using the above-described system a number of transactions 
15 may be carried in the e-commerce arena. For example, various 
access methods may be used to confirm on-line purchases from 
a merchant's web site. Two exemplary methods for confirming 
on-line purchase involve either browser access (FIGURE 6) or 
mobile access via SMS (FIGURE 7) . However, it should be 
20 realized that the present invention is not limited to these 
types of confirmation access methods and other types may be 
implemented . 
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Within the browser access method, a merchant must adopt 
its own purchase transaction implementation on a web server 
200 associated with a presentation system 15d. A verification 
is performed using the middleware 35. Confirmation is done 
5 solely between the merchant web server 200 within the 
presentation system 15d, the consumer web browser 205 within 
the presentation system 15d and the transaction system 15b. 
The exact implementation of the purchase transaction depends 
upon the transaction system 15b used. The typical 

10 implementation involves the use of a digital X509 certificate 
210 installed within the web browser 205 of the consumer. 
Information about the certificate 210 is also stored within 
the transaction system 15b, and is used to identify the 
consumer's account in the transaction system 15b when 

15 purchases are made. This normally means that purchases can 
only be made from a computer in which the consumer has a 
registered account, unless the certificate 210 is exported and 
copied to another computer. The only active role played by 
the middleware 35 in this case is for providing access between 

20 the presentation systems 15d and the transaction system 
account 15b. When a consumer decides to purchase an item on 
a web shop, the consumer is prompted to choose a certificate. 
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A certificate is used to digitally sign a contract which is 
transmitted to the transaction system via the merchant's web 
server 200. 

Using wireless technologies (FIGURE 7) , it is possible to 
5 verify payments using wireless hand held devices such as a 
mobile telephone. A mobile access system must be tightly 
integrated with the payment system. All transactions must be 
dispatched as quickly as possible to the payment system but be 
handled in a controlled way through the middleware 35 (not 

10 shown) . A mobile access system should handle two tasks, 
sending and receiving SMS messages and acting as a proxy 
server for account certificates. Merchants would fetch these 
certificates and use them when communicating with the 
transaction systems 15b (not shown) . 

15 The electronic commerce system 10 of the present 

invention may also be used in transactions between businesses 
as is illustrated in FIGURE 8. In this example, the 
electronic commerce system 10 enables the transaction to be 
dispatched directly between a first company 250 and a second 

20 company 255 and acts as a trusted partner between the first 
company 250 and the second company 255. The electronic 
commerce system 10 manages the technical issues regarding the 
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dispatch of calls to the correct destination, and insures that 
the data format is kept constant between the two companies. 
The electronic commerce system 10 even has the capability of 
maintaining confidentiality with respect to customer data by 
5 rendering it invisible to a requesting party. As a trusted 
partner, the electronic commerce system 10 acts as an 
independent party, legally detached from the buyers and the 
sellers, that ensures that transactions are processed in a 
controlled manner. The electronic commerce system 10 provides 

10 protection from fraud, eavesdropping, and so on. While the 
present example illustrates an interconnection between only 
two companies, it should, of course, be realized that many 
more than two companies could be hooked up in this fashion 
enabling the exchange of data. 

15 In the example of FIGURE 8, first company 250 requests at 

260 the authentication of a particular customer and specific 
data related to this customer to the electronic commerce 
system 10. The electronic commerce system 10 takes this 
request 260 and forwards it in the proper format to a second 

20 company 255 to request authentication data for this customer. 
The second company 255 forwards this information relating to 
the customer at 265 back to the electronic commerce system 10 
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which provides the information at 270 to the first company 
250 . 

Using the foregoing system, an individual is able to more 
easily create an electronic commerce system without being 
5 required to completely build a system from the ground up. 
Building blocks from previously existing legacy systems may be 
utilized within various functionalities required for the 
electronic commerce system using the middleware 35 such that 
previously existing resources may be utilized. 
10 The previous description is of a preferred embodiment for 

implementing the invention, and the scope of the invention 
should not necessarily be limited by this description. The 
scope of the present invention is instead defined by the 
following claims . 
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